home *** CD-ROM | disk | FTP | other *** search
/ 2,000 Greater & Lesser Mysteries / 2,000 Greater and Lesser Mysteries.iso / computer / virus / mys00476.txt < prev    next >
Encoding:
Text File  |  1994-06-10  |  19.0 KB  |  319 lines

  1. Portal-Rmail-To: garyt@cup.portal.com
  2. Received: by portal.com (3.2/Portal 8)
  3.     id AA13166; Wed, 26 Apr 89 01:38:31 PDT
  4. Received: from Sun.COM (arpa-dev) by sun.Sun.COM (4.0/SMI-4.0)
  5.     id AA18573; Tue, 25 Apr 89 23:08:58 PDT
  6. Received: from sun by Sun.COM (4.1/SMI-4.0)
  7.     id AB12617; Tue, 25 Apr 89 23:08:11 PDT
  8. Message-Id: <8904260608.AB12617@Sun.COM>
  9. Received: from LEHIIBM1.BITNET by IBM1.CC.Lehigh.Edu (IBM VM SMTP R1.2) with BSMTP id 5946; Wed, 26 Apr 89 02:02:49 EDT
  10. Received: by LEHIIBM1 (Mailer R2.03A) id 5722; Wed, 26 Apr 89 02:02:45 EDT
  11. Date:         Wed, 26 Apr 89 02:02:44 EDT
  12. From: Revised List Processor (1.5o) <LISTSERV@IBM1.CC.Lehigh.Edu>
  13. Subject:      File: "V101 3" being sent to you
  14. To: "Gary F. Tom" <sun!portal!cup.portal.com!garyt>
  15.  
  16. Subject: Virus 101: Chapter 3
  17. From: woodside@ttidca.TTI.COM (George Woodside)
  18. Newsgroups: comp.sys.atari.st,comp.sys.apple,comp.sys.mac,comp.sys.ibm.pc
  19. Date: 13 Mar 89 14:24:23 GMT
  20. Reply-To: woodside@ttidca.tti.com (George Woodside)
  21. Organization: Citicorp/TTI, Santa Monica
  22.  
  23. First, the mail:
  24.  
  25. Addressing a controversial topic is sure to generate some strong responses,
  26. and this one is no exception. Mail of the "Thank You" flavor outweighs the
  27. "You Idiot" flavor by about 4-1, so I'll be pressing on. The majority of the
  28. "You Idiot" mail is from senders who either admit, or display, limited
  29. programming ability. For the benefit of those individuals: I appreciate your
  30. concern. I am not attempting to aid in the spread of viruses, but in your
  31. own understanding of them, and ability to defend yourself. People with the
  32. ability to create a working virus will have found little or nothing they
  33. didn't already know in the preceeding postings. There is certainly nothing
  34. in them that isn't already available in the most fundamental books about
  35. personal computers. The preceeding postings are also written at a
  36. superficial level, and are missing quite a few specific things necessary to
  37. make a real working virus. Those missing items would add nothing to the
  38. layman's understanding of how a virus spreads or works, so are not included.
  39. You need not take my word for this; contact anyone you know who is
  40. knowledgeable in the system software field, and they will confirm it.
  41.  
  42. Sin of omission:
  43.  
  44. Part of a message received from Forrest Gehrke (feg@clyde.att.com):
  45.  
  46. ...One method for a virus finding enough space to hide itself, that I have
  47. seen, you have not mentioned. I have noticed that the so-called Pakastani
  48. virus uses non-standard sectoring at tracks 37 and 38 for IBM PC
  49. diskettes...
  50.  
  51. Mr. Gehrke is quite right. I did forget to mention this technique. While I
  52. had heard rumors of it being in use, I hadn't seen it in any of the virus
  53. code I've captured (again, I'm in the Atari ST world).
  54.  
  55. I have responded to all mail I have recieved (if it requested a response)
  56. including mailing out copies of missed chapters. Several responses have been
  57. returned by various mailers. If you requested something, and haven't heard
  58. from me, either your request or my response failed.
  59.  
  60. Now, Chapter 3:
  61.  
  62. Once a virus has installed itself, and replicated as frequently as it has
  63. found the opportunity, it will eventually launch whatever form of attack it
  64. was originally designed to do. That attack is the real purpose of the
  65. existance of the virus. Everything up to this point has been for the sake of
  66. getting to this stage.
  67.  
  68. What will it do? Almost anything. The limits are imagination and code space.
  69. The most benign virus I've seen claims to be an anti-virus. It blinks the
  70. screen on boot-up. The idea is that if you see the screen blink, you know
  71. that the benign virus is on the disk, rather than a more malicious one. It
  72. does, however, spread itself just like any other virus. From there, things
  73. proceed through the prank levels, time-triggered, messages, ones which try
  74. to simulate hardware failures, to ones which destroy files and disks. The
  75. actions vary from virus to virus. And, of course, there is a whole different
  76. library of viruses for each machine type. Attempting to detect a virus by
  77. describing or recognizing the symptoms is not only a task of limitless
  78. proportions, it is too little too late. When the symptoms appear, the damage
  79. has already been done.
  80.  
  81. Several viruses attempt to simulate hardware problems. (Conversly, I've had
  82. several pleas for help with a virus that proved to be other types of
  83. failures.) Frequently these viruses use timers to delay their actions until
  84. the system has been running for some time, and to spread out their
  85. activities to make the problem appear intermittent. Such virus induced
  86. glitches include occasionally faking succesful disk I/O, while actually not
  87. performing the read or write, altering the data being read or written, and
  88. (more commonly) screen display glitches. It is very difficult for anyone to
  89. determine whether such incidents are the results of a virus, or a real
  90. hardware problem. When such incidents start to occur on your system, start
  91. executing whatever virus detection software you have available, before
  92. lugging your system off to a service firm.
  93.  
  94. Previously, I mentioned the use of write protected disks as a step in the
  95. right direction to protect yourself. A large percentage of personal computer
  96. systems now use hard disk systems. Floppy disks are more often a backup
  97. media, or offline storage of files not needed on the hard disk for day to
  98. day use. Backing up requires the disks to be writeable, as does archiving
  99. off the infrequently used files. It is good practice to write protect the
  100. archived disks as soon as the files are copied to them. Run whatever virus
  101. checking software you have on the archive disks, write protect them, and
  102. then file them away.
  103.  
  104. (When reading the following suggestions about protecting your system from
  105. attacks, keep in mind that not all techniques can be applied to all systems
  106. or all software. Read the documentation accompanying the software before
  107. your first attempt to use it. Be familiar with what it is expected to do
  108. before you run it, and you'll be more able to recognize unexpected activity.)
  109.  
  110. The next step is to apply write protection to whatever disks you recieve
  111. software distributed on, before ever inserting them into a computer. Be they
  112. Public Domain, User Group Libraries, Commercial Software, or whatever, write
  113. protect them before you first read them. Then, make a backup copy if
  114. possible. Finally, when first executing the new software, have only write
  115. protected disks in your system. You should be well aware of any legitimate
  116. attempt to write to a disk by the software before it happens, and have
  117. adequate opportunity to insert a writeable disk when the proper time comes.
  118. This will not only give you a clue to the presence of a virus in the new
  119. software, but also protect the new software from a virus already resident in
  120. your system.
  121.  
  122. If your system supports the use of a RAM disk, copy new software into the
  123. RAMdisk before executing it the first time. Put write protected disks in
  124. the drives, then execute the software from the RAMdisk. If the software has
  125. no reason to access other disks, especially when starting itself up, be
  126. very suspicious of any disk activity. The most common time for a virus or
  127. trojan horse program to do it's dirty work is at startup, when it is
  128. impossible to tell whether disk access is part of program loading, or some
  129. clandestine operation. By having the software loaded into and executing
  130. from memory, you will be able to detect any disk I/O which occurs.
  131.  
  132. Finally, backup everything. Hard disks, floppy disks, tapes, whatever. Make
  133. backup copies, write protect them, and store them in a safe place off-line.
  134. If you are attacked by a dstructive virus, your first problem is to rid your
  135. system of the virus. Do not go to your off-line backups until you have
  136. determined if your problem came from a virus, and if so, that you have
  137. removed it from the system. A backup is useless if you give a virus a chance
  138. to attack it as well as your working copy.
  139.  
  140. A significant portion of these three chapters have been related to boot
  141. sector viruses. While the most common type in the Atari and MS-DOS world,
  142. they are certainly not the only type.
  143.  
  144. What follows is next is mostly a re-phrasing of an article from "Los Angeles
  145. Computer Currents", June, 1988. There are a few direct quotes from the
  146. copyrighted article. While I do not agree with all that this article states,
  147. I can not disprove the items from a position of experience. Since my efforts
  148. here are to inform, you may judge for yourself. A significant portion of my
  149. remarks are oriented to the Atari ST, but the concept is true to most all
  150. personal computers.
  151.  
  152. An article in that issue, by Lewis Perdue, outlined the problems he faced
  153. when the IBM PC running Ventura Publisher he was using to create the first
  154. issue of PC Management Letter became infected. I won't begin to copy all
  155. that, but the most interesting part of the recovery task was when they used
  156. a normal (high-level) format program to clear the hard drive. It didn't kill
  157. the virus. They had to resort to a low level format, and rebuild from all
  158. original distribution disks. Their backups had been infected as well as
  159. their working copies of the software. They relied on a PC specific tool
  160. called Data Physician, by Digital Dispatch, to aid in the detection of the
  161. virus. It implements techniques to diagnose infections, but it has to be
  162. installed before the virus strikes.
  163.  
  164. Another, more interesting aspect of the article, was categorizing viruses
  165. into four groups: Shell, Intrusive, Operating System, and Source.
  166.  
  167. Shell - these "wrap themselves around a host program and do not modify the
  168. original program." In laymen's terms, such a virus would tack itself onto a
  169. program file, so it would get loaded with the program. It would have to do
  170. this in a manner that would cause itself to be executed before the host,
  171. since the host certainly would not pass control to the virus.
  172.  
  173. This would be quite a complex task on an Atari ST (and on systems with a
  174. similar structure for executable program files). The virus program would
  175. have to be quite large in order to deal with the structure of an executable
  176. file on the ST. In simple terms, an executable file (a program) is a series
  177. of unique sections: a header, the code, data, a relocation map, and possibly
  178. a symbol table. The header specifies the size of each of the following
  179. segments. The code is the program, but in a form which will not run until it
  180. has been relocated. The data is constants, literals, messages, graphic data,
  181. etc. The relocation map tells the ST what changes to make to the code before
  182. it can be run. The symbol table is not usually present, except during
  183. program development. The reason behind this structure is that when a program
  184. is created, it does not know where in memory it will reside when it is
  185. executed. Things like RAMdisks, device drivers, accessories, printer
  186. buffers, spelling checkers, and so on, may or may not be present in the
  187. computer when the program is run. Since each of those things require memory,
  188. the place where the program will wind up being loaded is unknown.  So, when
  189. it does get loaded, it has to be told where it is. And, since the program
  190. will almost always contain references to itself (subroutines, variables,
  191. etc.) it has to be modified so that those references point to the right
  192. place. That's what the relocation map is for. It details how the program has
  193. to be modified. Once the program is loaded into memory, and fixed up, the
  194. relocation map and symbol table are discarded. So, to hook into a program
  195. file, a virus would have to split the program file, attach itself to the
  196. beginning of the code segment, (that's where execution begins), re-attach
  197. the data, relocation, and (possibly) symbol table segments, update the
  198. relocation map (all the original references would now have moved), update
  199. the header, then re-write itself to the original disk, assuming there was
  200. room on the disk for the (now bigger) file and that the disk was not
  201. write-protected. That's a large amount of work to develop, and a large
  202. amount of code to sneak into a system for the original infection.
  203.  
  204. I should mention here that it is not difficult to write "position
  205. independant" code on most micro-processors. You have to set out to do that,
  206. though, and take the necessary steps along the way to keep everything
  207. position independant.  Boot sector code is a well known example. The address
  208. where the boot sector will be loaded into memory is unknown, and there is no
  209. relocation done on the code. It has to be position independant.  It also has
  210. to fit in the boot sector. If it needs more than the amount of space in the
  211. boot sector, it has to determine its own location, and load the additional
  212. code itself. Of course, that means that it had to have a place to store the
  213. additional code, and it had to know where to find it.  Those items were
  214. covered previously.
  215.  
  216. Detecting a "Shell" type virus is not difficult. When it attaches itself to
  217. the target program, it must increase the size of the file. While it would be
  218. a real nusiance to check file sizes on a regular basis, there are programs
  219. available to do this for you. An "alteration detection" program will
  220. typically accept a list of programs to recognize. It will write a data file
  221. of its own, noting characteristics of each file in the list, such as length
  222. and date, and then run a numeric algorithm across the file. The numeric
  223. algorithm (typically a Cyclic Redundancy Check, or CRC) will yield a value
  224. which is stored in the alteration detection program's own data file. Then,
  225. on each subsequent execution of the alteration detection program, it checks
  226. the recorded characteristics of each file in its list, and re-executes the
  227. algorithm on the files. It reports back any file which has been changed
  228. since it last executed. Needless to mention, such a program must be run on
  229. the files to be monitored before any virus has an opportunity to attach
  230. itself to those files. Then, it must be run frequently to have a chance to
  231. detect altered files.
  232.  
  233. (Back to the types of viruses defined in the article)...
  234.  
  235. Intrusive - Intrusive viruses work by patching themselves into an existing
  236. program. This type of virus has two possibilities - either it is willing to
  237. render the host program useless, or it will attempt to co-exist with the
  238. host. If it is willing to corrupt the host, this is not too difficult a
  239. task. It would replace a part of the host program, modify the relocation
  240. map, and wait to get run. When it did, it would abandon the original task of
  241. the host program, and launch its attack. An example of this would be the
  242. virus bearing version of a word processor which struck the IBM compatible
  243. market some years ago. It signed on, looking just like a popular shareware
  244. program, but it was busy re-formatting the hard disk while the user waited
  245. for it to load and get ready to accept input.
  246.  
  247. The other flavor of intrusive virus, which attempts to co-exist with the
  248. host program, is terribly difficult to create. It has to modify the host in
  249. a manner that either accomplishes the host's task while also doing it's own,
  250. or find a part of the host that is infrequently or no longer used, and hide
  251. there. It would then have to modify some other part of the host in order to
  252. get itself executed. In either case, a virus of this type has to be aimed at
  253. one specific host program. There's no way it could perform the analysis
  254. necessary to locate such portions of a randomly selected program.  For that
  255. reason, an intrusive virus has to target some program that resides on a
  256. large portion of the target computer's installations, and that it is certain
  257. will be available to tamper with when the virus introduction occurs. That
  258. normally means either the Operating System, or some utility program so
  259. common that it is found virtually every where.
  260.  
  261. Operating System viruses work by replacing a portion of the Operating System
  262. with their own code. This is similar to the intrusive type, except that it
  263. can use a new trick (and there are ones that do this on the IBM/MS-DOS
  264. computers). As a part of the operating system, it can sneak out to a hard
  265. disk, find an unused part, mark it as defective, and hide there.  That would
  266. mean only a very small part of the code would have to be hooked into the
  267. operating system (possibly as an entry in a list of device initializing
  268. routines). That small segment could then allocate adequate memory for the
  269. real routine, and load it from wherever.
  270.  
  271. Source Code viruses - I found this type of virus to be a bit unbelievable.
  272. The article reads (I quote):
  273.  
  274.         Source code viruses are intrusive programs that are inserted into a
  275.         source program such as those written in Pascal prior to the program
  276.         being compiled.  These are the least-common viruses because they are
  277.         not only hard to write, but also have a limited number of hosts
  278.         compared to other types.  (end quote)
  279.  
  280. Sounds to me like this would be nearly impossible to accomplish in
  281. after-market software. If, on the other hand, they mean a part of the
  282. program added by a devious member of a development team, then, it is
  283. credible. It brings to mind the story (which I can't verify, but I've heard
  284. it from enough different sources to believe it is true) about what may well
  285. have been the first virus. In case you're not familiar with "C" compilers,
  286. they are usually several different programs, which must be run in proper
  287. sequence, passing files and options from one to the next. Usually, this is
  288. all done by a another program, a "compiler driver", which is almost always
  289. called "cc". You execute "cc", passing it the necessary flags, and the
  290. name(s) of the program(s) you want compiled, and it drives all the necessary
  291. tasks to do it.
  292.  
  293. This was reported to have been done by one of the originators of the UNIX
  294. operating system, (name deleted), back in the development days at Bell Labs.
  295. Well, the story goes, he wrote the first versions of UNIX, "C", and "cc". He
  296. had a "back door" to get into a system running UNIX. He built the back door
  297. code into "cc". The code in "cc" checked to see what it was compiling. If it
  298. was the module "login", it incorporated the back door into the module, so
  299. that he could get into the system. If, on the other hand, it was compiling
  300. "cc", it included the code both to re-create itself, and the code to build
  301. the back door into "login". So, every "cc" had the code, and consequently
  302. every UNIX system included the back door. Eventually, it was discovered, and
  303. removed. There followed a frantic rebuilding of every UNIX system in
  304. existance, so the story goes.
  305.  
  306. This is the final chapter which will be distributed via cross-posting.
  307. Chapter 4 will relate specifically to viruses captured in the Atari ST
  308. environment, and will be posted only to comp.sys.atari.st. It will come out
  309. about 1 week after this one. This article was posted on March 13, 1989, so
  310. you can determine the approximate delay to your receipt, in case you don't
  311. read that newsgroup, but wish to locate the fourth chapter in
  312. comp.sys.atari.st.
  313.  
  314. End of Chapter 3.
  315.  
  316. --
  317. *George R. Woodside - Citicorp/TTI - Santa Monica, CA
  318. *Path:       ..!{philabs|csun|psivax}!ttidca!woodside
  319.